The session initiation protocol is a standard for the Voice over Internet Protocol (“VoIP”), which was published by the Internet Engineering Task Force (“IETF”) in March, 1999.
The SIP signaling protocol is adapted to initiate, manage and terminate voice and video sessions in a packet network and particularly to generate, modify and terminate a session of a participant or between the participants. The SIP is one of components constituting a multimedia data and control architecture of the IETF and is associated with numerous other protocols from the IETF, such as the Real time Transfer Protocol (“RTP”), the Session Description Protocol (“SDP”), etc.
The SIP primarily provides five functions related to session establishment and termination:
(1) User locating: a decision of a terminal system for communication;
(2) User availability: a decision of willingness of a called party participating in communication;
(3) User capability: a decision of media and media parameters in use;
(4) Session establishment: “ringing”, setting up of session parameters for calling and called parties; and
(5) Session management: including session transfer and termination, session parameter modification, service invocation, etc.
The SIP involves two types of messages:
(1) Request: messages sent from a client to a server; and
(2) Response: messages sent from a server to a client.
Particularly, the request messages include:
INVITE: initialize a call;
ACK: acknowledge the final reply for INVITE;
BYE: terminate a call;
CANCEL: revoke searching and ringing;
OPTIONS: inquiry about capabilities of another part;
REGISTER: register for a location service;
INFO: send information during a session without changing the session status;
PRACK: function the same as ACK but for a temporary response;
SUBSCRIBE: subscribe to a remote terminal for a notification of change of the status of the remote terminal;
NOTIFY: notify a subscriber of change of the status subscribed by the subscriber;
UPDATE: allow a client to update parameters of a session without influencing the current status of the session;
MESSAGE: achieve an instant message through loading contents of the instance message into a request body of MESSAGE; and
REFER: instruct a receiver to contact a third party dependent upon information on a contact address provided in a request.
The response messages include digital response codes. A set of response codes in the SIP is partially based upon Hyper Text Transport Protocol (HTTP) response codes. There are two types of responses:
A temporary response (1XX): adapted to indicate a process by a server, but not to terminate an SIP transaction; and
A final response (2XX, 3XX, 4XX, 5XX, 6XX): terminate an SIP transaction.
Each SIP message consists of the following three parts:
(1) Start Line: each SIP message starts with the Start Line. The Start Line conveys the type of the message (a method type in a request and a response code in a response) and the version of the protocol. The Start Line can be a request line (for a request) or a status line (for a response).
(2) SIP Header: it is adapted to transport the attribute of the message and to modify the meaning of the message. It is identical to an HTTP header field in syntax and semantic (actually some headers are derived from the HTTP) and is always in a format of <Name>:<Value>.
(3) Message Body: it is adapted to describe an initiated session (for example, an audio and video coding type, a sampling rate, etc. are included in a multimedia session). The Message Body can be presented in a request and a response. The SIP distinguishes clearly signaling information transported in the SIP Start Line and the SIP Header from session description information beyond the SIP. An available body type may include the SDP later described in the context.
From the year of 1999 on, the essential SIP protocol has been developed from the initial RFC 2543 to the current RFC 3261 with both greatly extended protocol contents and a more improved signaling framework. Using the SIP to only accomplish a basic call control is no longer satisfactory, and more attention is paid to how to use the SIP to implement added-value services flexibly.
A SUBSCRIBE/NOTIFY mechanism has been presented in the SIP protocol so that an entity (subscriber) in a network may subscribe for status information of a resource or call in the network. When the status of the subscribed resource changes, a network entity (notifier) responsible for the resource can send to the subscriber a notification which notifies about the current change of the status of the resource. Here, the subscriber initiates via an SIP SUBSCRIBE message to the notifier a request for subscribing to an event, and the notifier returns a subscription notification via an SIP NOTIFY message.
When an event is subscribed successfully, both the subscriber and the notifier create their respective subscription instances for the subscribed event. The subscribed event is provided with a lifetime period determined by both a value of Expires in the SUBSCRIBE/NOTIFY message and a lifetime period of a current SIP session identifier. When the value of Expires is reached, the subscriber is required to resend a SUBSCRIBE message so as to refresh the subscription instance if the subscriber wishes continuous acquisition of notification of the subscribed event. If the lifetime period of the current SIP session identifier is ended, e.g. the subscriber goes offline, the lifetime period of the subscription instance will be ended as well. The subscriber is required to send a SUBSCRIBE message with a value of Expires being “0” if the subscriber wishes to revoke the subscription before the lifetime period of the subscription instance is ended.
In practical applications, the following issues may exist in the above solutions. When a user wishes to initiate a permanently valid subscription, a terminal of the user (subscriber) is required to stay online all the time. For example, a user with subscription to a voice mail box may wish to be notified about a new voice message provided that the mail box is valid. In the prior art, however, a subscription instance will be ended if the user goes offline. A demand for a scenario of permanent subscription can be satisfied only if a request for subscribing to a voice message event is initiated from the user in his own initiative or automatically from the user terminal capable of recognizing the attempt of the user (for permanent subscription) when the user gets online again, which means an additional requirement on both the user and the user terminal, let alone the absence in the SIP protocol of a method for the user terminal to recognize the attempt of the user for permanent subscription.
Further, if the user wishes to initiate a temporarily valid once subscription, subscription will be revoked automatically upon finishing a service for a subscribed event. It may be difficult for the user terminal to set a specific value for the period of subscription. For example, the user who receives an anonymous malicious call subscribes to a network device for a malicious call tracing event. Here, the user subscribes for a current status of the subscribed event (an identifier of a caller initiating the malicious call) instead of change of a status. And, the notifier itself may not know the identifier of the caller initiating the malicious call, either, and is required to request another network element in turn. Therefore, there may be an indeterminate interval from reception of subscription by a notifier to sending of a notification from the notifier, so that it may be even more difficult for the user to set a value for the period of subscription. If the value for the period of subscription is set too small, a subscription failure may occur in that a created subscription instance may have already be invalidated when the user terminal receives a subscribed notification. If the value is set too large, the subscriber and the notifier may have to perform an additional process in that the subscription instance may be still valid even if the call is released.
Further, since the current SUBSCRIBE/NOTIFY mechanism offers no subscription based upon a time policy, the user can not initiate any subscription specifying a start time at which a subscription instance gets validated and a time at which a subscribed notification is sent. For example, the user will be out for business three days later, and wishes subscription to a weather forecast of the following three days regarding the city for business. In other words, a service provider will start sending to the user the weather forecast three days later. For another example, the user with subscription to a weather forecast wishes that the service provider would send the weather forecast at his own specified time because the sending time of the service provider does not comply with his life schedule. The current SUBSCRIBE/NOTIFY mechanism can not meet such demands of the user.